home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1993
/
Internet Info CD-ROM (Walnut Creek) (1993).iso
/
inet
/
internet-drafts
/
draft-braden-shared-media-00.txt
< prev
next >
Wrap
Text File
|
1993-10-18
|
36KB
|
941 lines
Internet Draft R. Braden
Expires: April 1994 USC-ISI
<draft-braden-shared-media-00.txt> Jon Postel
USC-ISI
Yakov Rekhter
IBM Research
October 1993
Internet Architecture Extensions for Shared Media
Status of This Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months. Internet-Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet-
Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.''
Abstract
The original Internet architecture assumed that each network is
labeled with a single IP network number. This assumption is violated
for shared media, such as large public data networks. The
architecture still works if this is violated, but some unnecessary
host-router and router-router hops may result. This memo discusses
alternative approaches to extension of the Internet architecture for
efficient use of shared media.
1. INTRODUCTION
This memo concerns the implications of shared medium networks for the
architecture of the TCP/IP protocol suite. General familiarity with
the TCP/IP architecture and the IP protocol is assumed.
The Internet architecture is founded upon what was originally called
the "Catenet model" [PSC81]. Under this model, the Internet
(originally dubbed "the Catenet") is formed using routers (originally
called "gateways") to interconnect distinct and perhaps diverse
networks. An IP host address (more correctly characterized as a
Braden, Postel, Rekhter Expires: April 1994 [Page 1]
Internet Draft Shared Media IP Architecture October 1993
network interface address) is formed of the pair (net#,host#). Here
"net#" is a unique IP number assigned to the network (or subnet) to
which the host is attached, and "host#" identifies the host on that
network (or subnet).
The original Internet model made the implicit assumptions that each
network has a single IP network number and that networks with
different numbers may interchange packets only through routers. This
assumption may be violated for networks implemented using a common
"shared medium" (SM) at the link layer (LL). For example, in
operational environments, network managers sometimes want to
configure multiple IP network numbers (usually subnet numbers) on a
single Ethernet. Potentially more important examples of shared media
are provided by the proposed large (switched) public data networks
(LPDNs).
This memo concerns a set of changes that will provide the desired
efficiency in an SM while retaining the coherence of the existing
architecture. This issue has arisen in a number of IETF Working
Groups concerned with LPDNs, including IPLPDN, IP over ATM, IDRP for
IP, and BGP. It is clearly time to take a careful look at the
architectural issues to be solved.
This memo first summarizes the relevant aspects of the original
architecture (Section 2), and then it shows the effect of introducing
shared media networks and the problems to be solved (Section 3).
Then it discusses possible solutions (Section 4).
2. THE ORIGINAL ARCHITECTURE
We very briefly review the original architecture, to introduce the
terminology and concepts we need. Figure 1 illustrates a typical set
of four networks A, ... D, represented traditionally as clouds,
interconnected by routers R2, R3, and R4. Routers R1 and R5 connect
to other parts of the Internet. Ha,
It is not necessary to distinguish between network and subnet in this
memo. We may assume that there is some address mask associated with
each "network" in Figure 1, allowing a host or router to divide the
32 bits of an IP address into an address for the cloud and a host
number that is defined uniquely only within that cloud.
Braden, Postel, Rekhter Expires: April 1994 [Page 2]
Internet Draft Shared Media IP Architecture October 1993
Ha Hb Hc Hd
| | | |
| | | |
_|_ _|_ _|_ _|_
( ) ( ) ( ) ( )
(Net) (Net) (Net) (Net)
( A ) ( B ) ( C ) ( D )
- R1 --( )-- R2 --( )-- R3 --( )-- R4 --( )-- R5 --
( ) ( ) ( ) ( )
(___) (___) (___) (___)
Figure 1. Example Internet Fragment
An Internet router is connected to local network(s) as a special kind
of host. Indeed, for network management purposes, a router plays the
role of a host by originating and terminating datagrams. However,
there is an important difference between a host and a router: the
routing function is mostly centralized in the routers, allowing hosts
to be "dumb" about routing. Internet hosts [RFC-1122] are required
to make only one simple routing decision: is the destination address
local to the connected network? If the address is not local, we say
it is "foreign" (relative to the connected network).
A host sends a datagram directly to a local destination address, or
for a foreign destination, to a first-hop router. The host initially
uses some "default" router for any new destination address. If the
default is the wrong choice, that router returns a Redirect message
and forwards the datagram. The Redirect message specifies the
preferred first-hop router for the given destination address. The
host uses this information, which it maintains in a "routing cache"
[RFC-1122], to determine the first-hop address for subsequent
datagrams to the same destination.
To actually forward an IP datagram across a network hop, the sender
must have the link layer (LL) address of the target. Therefore, each
host and router must have some "address resolution" procedure to map
IP address -> LL address. ARP, used for networks with broadcast
capability, is the most common address resolution procedure
[Plummer82]. If there is no LL broadcast capability (or if it is too
expensive), then there are two other approaches to address
resolution: local configuration tables, or some server that can be
consulted using point-to-point transmission in the local medium. We
will refer to the last as an "address-resolution server", or AR
Server. Hosts would be configured with the LL address(es) of AR
Server(s), while the servers would ultimately depend upon configured
tables of LL address(es).
Braden, Postel, Rekhter Expires: April 1994 [Page 3]
Internet Draft Shared Media IP Architecture October 1993
The examples in this memo use ARP for address resolution. At least
some of the LPDN's that are planned will provide sufficient broadcast
capability to support ARP. It is important to note that ARP operates
at the link layer, while the Redirect and routing cache mechanisms
operate at the IP layer of the protocol stack.
3. THE PROBLEMS INTRODUCED BY SHARED MEDIA
Figure 2 shows the same configuration as Figure 1, but now networks
A, B, C, and D are all within the same shared medium (SM), shown by
the dashed box enclosing the clouds. Networks A, ... D are now
logical IP networks (called LIS's in [Laubach93]) rather than
physical networks, and each of these logical networks may (or may
not) be administratively distinct. The SM allows direct connectivity
between any two hosts or routers connected to it. For example, host
Ha can interchange datagrams directly with host Hd or with router R4.
A router that has some but not all of its interfaces connected to the
shared medium is called a "border router"; R5 is an example.
Ha Hb Hc Hd
| | | |
---- | ---------- | ---------- | ---------- | ----
| __|__ __|__ __|__ __|__ |
( ) ( ) ( ) ( )
| ( ) ( ) ( ) ( ) |
( Net ) ( Net ) ( Net ) ( Net )
| ( A ) ( B ) ( C ) ( D ) |
( ) ( ) ( ) ( )
| ( ) ( ) ( ) ( ) |
(_____) (_____) (_____) ( ____)
| | | | | | | | | |
--- | | -------- | | -------- | | -------- | | ---
| | | | | | | |
- R1 - --- R2 --- --- R3 --- --- R4 --- --- R5 ---
Figure 2. Logical IP Networks in Shared Medium
Figure 2 illustrates the "classical" model [Laubach93] for use of the
Internet architecture within a shared medium, i.e., simply applying
the original Internet architecture described earlier. This will
provide correct but not optimal operation.
For example, in the case of two hosts on the same logical network
Braden, Postel, Rekhter Expires: April 1994 [Page 4]
Internet Draft Shared Media IP Architecture October 1993
(not shown in Figure 2), the original rules will clearly work; the
source host will forward a datagram directly in a single hop to a
host on the same logical network. The original rules will also work
for communication between any pair of hosts shown in Figure 2.
However, the classical model does not take advantage of the direct
connectivity allowed by the shared medium.
Suppose host Ha wants to send a datagram to Hd; the original
architecture will use the four-hop path Ha -> R2 -> R3 -> R4 -> Hd
instead of the direct path Ha -> Hd. The extra hops may be
desirable, as they allow the routers to act as administrative
firewalls. On the other hand, when such firewall protection is not
required, it should be possible to take advantage of the shared
medium to allow this datagram to use shorter paths. In general, it
should be possible to choose between firewall security and efficient
connectivity. This memo concerns how to achieve minimal-hop
connectivity when it is desired.
Note that ARP requires LL broadcast. Even if the SM supports
broadcast, it is likely that the administrators will erect firewalls
to keep broadcasts local to their LIS.
There are three cases to be optimized. Suppose H and H' are hosts
and Rb and Rb' are border routers connected to the same same SM.
Then the following one-hop paths should be possible:
H -> H': Host to host within the SM
H -> Rb: Host to exit router
Rb -> Rb': Entry boder router to exit border router,
for transit traffic.
We may or not be able to remove the extra hop implicit in Rb -> R ->
H, where the ultimate source is outside the SM. To remove this hop
would require distribution of host routes, not just network routes,
between the two routers R and Rb.
There are a number of important requirements for any architectural
solution to these problems.
* Interoperability
Modified hosts and routers must interoperate with unmodified
nodes.
Braden, Postel, Rekhter Expires: April 1994 [Page 5]
Internet Draft Shared Media IP Architecture October 1993
* Practicality
Minimal software changes should be required.
* Robustness
The new scheme must be robust against errors in software,
configuration, or transmission.
* Security
The new scheme must be securable against subversion.
The distinction between host and router is very significant from an
engineering viewpoint. It is considered to be much harder to make a
global change in host software than to change router software,
because there are many more hosts and host vendors than routers and
router vendors, and because hosts are less centrally administered
than routers. If it is necessary to change the specification of what
a host does (and it is), then we must minimize the extent of this
change.
4. SOME SOLUTIONS TO THE SM PROBLEMS
Four different approaches have been suggested for solving these SM
problems.
(1) Iterated Redirects
In this approach, the host Redirect mechanism is extended to
collapse multiple-hop paths within the same shared medium, hop-
by-hop. A router will be allowed to send, and a host will be
allowed to accept, a Redirect message that specifies a foreign
IP address within the same SM. We refer to this as a "foreign
Redirect".
(2) Extended Routing
Routing protocols can be modified to know about the SM and to
provide LL addresses.
(3) Extended Proxy ARP
This is a form of the proxy ARP approach, in which the routing
problem is solved implicitly by an extended address resolution
mechanism at the LL. This approach has been described by
Heinanen [Heinanen93] and by Garrett et al [Garratt93].
Braden, Postel, Rekhter Expires: April 1994 [Page 6]
Internet Draft Shared Media IP Architecture October 1993
(4) Route Query Messages
This approach has been suggested by Halpern [Halpern93]. Rather
than adding additional information to routing, this approach
would add a new IP-layer mechanism, end-to-end query and reply
datagrams.
These four are discussed in the following four subsections.
4.1 Hop-by-Hop Redirection
The first scheme we consider would operate at the IP layer. It
would cut out extra hops one by one, with each router in the path
operating on local information only. This approach requires both
host and router changes but no routing protocol changes.
The basic idea is that the first-hop router, upon observing that
the next hop is within the same SM, sends a foreign Redirect to
the source, redirecting it to the next hop. Successive
application of this algorithm at each intermediate router will
eventually result in a direct path from source host to destination
host, if both are within the same SM.
Suppose that Ha wants to send a datagram to Hd. We use the
notation IP.a for the IP address of entity a, and LL.a for the
corresponding LL address. Each line in the following shows an IP
datagram and the path that datagram will follow, separated by a
colon. The notation "Redirect( h, IP.a)" means a Redirect
specifying IP.a as the best next hop to reach host h.
(1) Datagram 1: Ha -> R2 -> R3 -> R4 -> Hd
(2) Redirect(Hd, IP.R3): R2 -> Ha
(3) Datagram 2: Ha -> R3 -> R4 -> Hd
(4) Redirect(Hd, IP.R4): R3 -> Ha
(5) Datagram 3: Ha -> R4 -> Hd
(6) Redirect(Hd, IP.Hd): R4 -> Ha
(7) Datagram 4: Ha -> Hd
There are three problems to be solved to make this work.
IR1: Each router must be able to resolve the LL address of the
source Ha, to send a (foreign) Redirect.
Braden, Postel, Rekhter Expires: April 1994 [Page 7]
Internet Draft Shared Media IP Architecture October 1993
Let us assume that the link layer provides the source LL
address when an IP datagram arrives. If the router
determines that a Redirect should be sent, then it will be
sent to the source LL address of the received datagram.
IR2: A source host must be able to resolve the LL address of each
router to which it is redirected.
It would be possible for each router R, upon sending a
Redirect to Ha, to also send an unsolicited ARP Reply point-
to-point to LL.Ha, updating Ha's ARP cache with LL.R.
However, there is not guarantee that this unsolicited ARP
Reply would be delivered. If it was lost, there would be a
forwarding black hole. The host could recover by starting
over from the original default router; however, this may be
too obtuse a solution.
A much more direct solution would introduce an extended ICMP
Redirect message (call it XRedirect) that carries the LL
address as well as the IP address of the target. This
removes the issue of reliable delivery of the unsolicited ARP
described earlier, because the fate of the LL address is
shared with the IP target address; both are delivered or
neither are.
Using XRedirect and omitting the spurious router-router
XRedirects, the previous example becomes:
(1) Datagram 1: Ha -> R2 -> R3 -> R4 -> Hd
(2) XRedirect(Hd, IP.R3, LL.R3): R2 -> Ha
(3) Datagram 2: Ha -> R3 -> R4 -> Hd
(4) XRedirect(Hd, IP.R4, LL.R4): R3 -> Ha
(5) Datagram 3: Ha -> R4 -> Hd
(6) XRedirect(Hd, IP.Hd, LL.Hd): R4 -> Ha
(7) Datagram 4: Ha -> Hd
IR3: Each router should be able to recognize when it is the first
hop in the path, since a Redirect should be sent only by the
first hop router. Unfortunately this is not generally
possible, since a router in this chain determines the LL
address of the source only from the arriving datagram, as
indicated in IR1 above. Therefore, application of this
Braden, Postel, Rekhter Expires: April 1994 [Page 8]
Internet Draft Shared Media IP Architecture October 1993
technique by routers in the path after the first-hop router
will cause them to send spurious [X]Redirects; these will be
sent to the IP address of the source host, but using the LL
address of the previous-hop router. These will be ignored by
the routers and cause no harm.
The Host Requirements RFC [RFC-1122] specifies the host mechanism
for routing an outbound datagram in terms of sending the datagram
either directly to a local destination or else to the first hop
router to reach a foreign destination [RFC-1122 3.3.1]. However,
if the routing cache did specify a foreign target address, the
mechanism as described should forward the datagram directly to
that foreign address, as we require for efficient SM operation.
The target address contained in the routing cache is updated by
Redirect messages. There is currently a restriction on what
target addresses may be accepted in Redirect messages [RFC-1122
3.2.2.2]:
A Redirect message SHOULD be silently discarded if the new
router address it specifies is not on the same connected
(sub-) net through which the Redirect arrived, or if the
source of the Redirect is not the current first-hop router
for the specified destination.
The minimal change for SMs would remove the first validity check
and generalize the second, as follows:
A Redirect message SHOULD be silently discarded if the source
of the Redirect is not the current target address in the
routing cache for the specified destination.
Thus, the new validation test is that a Redirect must come from
the node to which we sent the datagram that triggered the
Redirect.
In order to send a datagram to the target address found in the
routing cache, a host must resolve the IP address into a LL
address. We assume that no change is necessary in the current
IP->LL resolution mechanism in the host to handle a foreign rather
than a local address. Thus, the only change required of a host is
to remove one of the validity checks on a Redirect message.
By design, the router changes required to improve SM efficiency
are much more extensive than the host changes. The examples given
earlier showed two kinds of additional router function.
Braden, Postel, Rekhter Expires: April 1994 [Page 9]
Internet Draft Shared Media IP Architecture October 1993
(1) Sending Foreign Redirects
Consider a router that is connected to an SM. When it
receives a datagram, it tests whether the next hop is on the
same SM, and if so, it sends a foreign XRedirect to the
source host, using the link layer address with which the
datagram arrived.
A router should avoid sending more than a limited number of
successive foreign Redirects to the same host. This is
necessary because an unmodified host may legitimately ignore
a Redirect to a foreign network and continue to forward
datagrams to the same router. A router can accomplish this
limitation by keeping a cache of foreign Redirects sent.
Note that foreign Redirects generated by routers according to
these rules, like the current local Redirects, may travel
exactly one link-layer hop. It is therefore reasonable and
desirable to set their TTL to 1, to ensure they cannot stray
outside the SM.
(2) SM-wise Routing
A modified routing protocol could allow a router to know
which other routers are in the same SM, in order to forward a
datagram directly to the last hop router within the SM. This
is discussed in the following section.
4.2 Extended Routing
The routing protocols may be modified to carry additional
information that is specific to the SM. The router could use the
attribute "SameSM" for a route to deduce the shortest path to be
reported to its neighbors. It could also carry the LL addresses
with each router IP address.
For example, the modified routing protocol would allow R2 to know
that R4 is the best next-hop to reach the destination network in
the same SM, and to know both IP.R4 and LL.R4. Then if Ha sends a
datagram to Hd:
(1) Datagram 1: Ha -> R2 -> R4 -> Hd
(2) XRedirect(Hd, IP.R4, LL.R4): R2 -> Ha
(3) Datagram 2: Ha -> R4 -> Hd
Braden, Postel, Rekhter Expires: April 1994 [Page 10]
Internet Draft Shared Media IP Architecture October 1993
(4) XRedirect(Hd, IP.Hd, LL.Hd): R4 -> Ha
(5) Datagram 3: Ha -> Hd
Note that we require the routing protocol to handle only per-
network information, not per-host information. This results in
the two-step redirection shown in this example.
There are three aspects to the routing protocol modification.
(1) The ability to pass "third-party" information -- a router
should be able to specify the address (IP address and perhaps
LL address) of some other router as the next-hop.
(2) Knowledge of the "SameSM" attribute for routes.
(3) The LL addresses corresponding to IP addresses of routers
within the same SM.
A router must be able to determine that a particular IP address
(e.g., the source address) is in the same SM. There are several
possible ways to make this information available to a router in
the SM.
(1) A router may use a single physical interface to an SM; this
implies that all its logical interfaces lie within the same
SM.
(3) There might be some administrative structure in the IP
addresses, e.g., all IP addresses within a particular
national SM might have a common prefix string.
(3) There might be configuration information, either local to the
router or available from some centralized server (e.g, the
DNS). Note that a router could consult this server in the
background while continuing to forward datagrams without
delay. The only consequence of a delay in obtaining the
"Same SM" information would be some unnecessary (but
temporary) hops.
4.3 Extended Proxy ARP
The approach of Heinanen [Heinanen93] was intended to solve the
problem of address resolution in a shared medium with no broadcast
mechanism ("Non-Broadcast, MultiAccess" or NBMA). Imagine that
the shared medium has a single IP network number, i.e., it is one
network "cloud". He envisions a set of AR Servers within this
Braden, Postel, Rekhter Expires: April 1994 [Page 11]
Internet Draft Shared Media IP Architecture October 1993
medium. These AR Servers run some routing protocol among
themselves. A source host issues an ARP Request (via a point-to-
point LL transmission) to an AR Server with which it is
associated. This ARP Request is forwarded hop-by-hop at the link
layer, through the AR Servers towards the AR Server that is
associated with the destination host. That AR Server resolves the
address (using information learned from either host advertisement
or a configuration file), and returns an ARP Reply back through
the AR Servers to the source host.
Ha Hb Hc Hd
| | | |
---- | ---------- | ---------- | ---------- | ----
( )
( Shared Medium (One Logical Network) )
( )
----|--|---------|------------|----------|----|---
| | | | | |
- R1 - | | | | --- R5 ---
____|__ __|____ __|____ _|_____
| AR Sa | | AR Sb | | AR Sc | | AR Sd |
|_______| |_______| |_______| |_______|
Figure 3. Single-Cloud Shared Medium
Figure 3 suggests that each of the hosts Ha, ... Hd is associated
with a corresponding AR Server "AR Sa", ..."AR Sd".
This same scheme could be applied to the LIS model of Figure 2.
The AR Servers would be implemented in the routers, and if the
medium supports broadcast then the hosts would be configured for
proxy ARP. That is, the host would be told that all destinations
are local, so it will always issue an ARP request for the final
destination. The set of AR Servers would resolve this request.
Since routing loops are a constant possibility, Heinanen's
proposal includes the addition of a hop count to ARP requests and
replies.
Like all proxy ARP schemes, this one has a seductive simplicity.
However, solving the SM problem at the LL has several costs. It
requires a complete round-trip time before the first datagram can
flow. It requires a hop count in the ARP packet. This seems like
a tip-off that the link layer is not the most appropriate place to
solve the SM problem in general.
Braden, Postel, Rekhter Expires: April 1994 [Page 12]
Internet Draft Shared Media IP Architecture October 1993
4.4 Routing Query Messages
This scheme [Halpern93] introduces a new IP level mechanism: SM
routing query and reply messages. These messages are forwarded as
IP datagrams hop-by-hop in the direction of the destination
address. The exit router can return a reply, again hop-by-hop,
that finally reaches the source host as an XRedirect. It would
also be possible (but not necessary) to modify hosts to initiate
these queries.
The query/reply pair is supplying the same information that we
would add to routing protocols under Extended Routing. However,
the Query/Reply messages would allow us to keep the current
routing protocols unchanged, and would also provide the extra
information only for the routes that are actually needed, thus
reducing the routing overhead. Note that the Query/Reply sequence
can happen in parallel with forwarding the initial datagram hop-
by-hop, so it does not add an extra round-trip delay.
5. Security Considerations
We should discuss the security issues raised by our suggested
changes. We should note that we are not talking about "real"
security here; real Internet security will require cryptographic
techniques on an end-to-end basis. However, it should not be easy to
subvert the basic delivery mechanism of IP to cause datagrams to flow
to unexpected places.
With this understanding, the security problems arise in two places:
the ICMP Redirect messages and the ARP replies.
* ICMP Redirect Security
We may reasonably require that the routers be secure. They are
generally under centralized administrative control, and we may
assume that the routing protocols will contain sufficient
authentication mechanisms (even if it is not currently true).
Therefore, a host will reasonably be able to trust a Redirect
that comes from a router.
However, it will NOT be reasonable for a host to trust another
host. Suppose that the target host in the examples of Section
4.1 is untrustworthy; there is no way to prevent its issuing a
new Redirect to some other destination, anywhere in the
Internet. On the other hand, this exposure is no worse than it
was; the target host, once subverted, could always act as a
hidden router to forward traffic elsewhere.
Braden, Postel, Rekhter Expires: April 1994 [Page 13]
Internet Draft Shared Media IP Architecture October 1993
* ARP Security
Currently, an ARP Reply can come only from the local network,
and a physically isolated network can be administrative secured
from subversion of ARP. However, an ARP Reply can come from
anywhere within the SM, and an evil-doer can use this fact to
divert the traffic flow from any host within the SM
[Bellovin89].
The XRedirect closes this security hole. Validating the
XRedirect (as coming from the node to which the last datagram
was sent) will also validate the LL address.
Another approach is to validate the source address from which
the ARP Reply was received (assuming the link layer protocol
carries the source address and the driver supplies it). An
acceptable ARP reply for destination IP address D can only come
from LL address x, where the routing cache maps D -> E and the
ARP cache gives x as the translation of E. This validation,
involving both routing and ARP caches, might be ugly to
implement in a strictly-layered implementation. It would be
natural if layering were already violated by combining the ARP
cache and routing cache.
It is possible for the link layer to have security mechanisms that
could interfere with IP-layer connectivity. In particular, there
could possible be non-transitivity of logical interconnection within
a shared medium. In particular, some large public data networks may
include configuration options that could allow Net A to talk to Net B
and Net B to talk to Net C, but prevent A from talking directly to C.
In this case, the routing protocols have to be sophisticated enough
to handle such anomalies.
6. CONCLUSIONS
We have outlined four possible extensions to the Internet
architecture to allow hop-efficient forwarding of IP datagrams within
shared media. The changes to hosts are minimal (indeed, some hosts
may require no changes at all). The changes to routers are more
extensive, but can be introduced gradually.
Our suggested extensions do not change the overall structure of the
Internet architecture. It would be possible to make (and some have
suggested) much more radical changes to accommodate shared media. In
the extreme, one could entirely abolish the inner clouds in Figure 2,
so that there would be no logical network structure within the SM.
The IP addresses would then be logical, and some mechanism of
distributed servers would be needed to find routes within this random
Braden, Postel, Rekhter Expires: April 1994 [Page 14]
Internet Draft Shared Media IP Architecture October 1993
haze. We think that throwing out what has been proven to work, and
work well, might make a good research paper but would not be good
Internet design strategy.
7. ACKNOWLEDGMENTS
We are grateful to Keith McGloghrie, Joel Halpern, and others who
rubbed our noses in this problem. We are also grateful to Gerri
Gilliland who supplied the paper tablecloth, colored crayons, and
fine food that allowed these ideas to be assembled initially.
8. REFERENCES
[Bellovin89] Bellovin, S. M., "Security Problems in the TCP/IP
Protocol Suite". ACM CCR, v. 19. no. 2, April 1989.
[Garrett93] Garrett, J., Hagan, J. and J. Wong, "Directed ARP",
RFC-1433, March 1993.
[Plummer82] Plummer, D., "An Ethernet Address Resolution
Protocol", RFC-826, November 1982.
[Halpern93] Halpern, J., Private communication, July 1993.
[Heinanen93] Heinanen, J., "NBMA Address Resolution Protocol
(NBMA ARP)", Work in Progress, June 1993.
[Laubach93] Laubach, M., "Classical IP and ARP over ATM", work in
progress, July 1993.
[Postel81a] Postel, J., "Internet Protocol", RFC-791, September
1981.
[Postel81b] Postel, J., "Internet Control Message Protocol",
RFC-792, September 1981.
[PSC81] Postel, J., Sunshine, C., and D. Cohen, "The ARPA
Internet Protocol". Computer Networks 5, pp 261-271, 1983.
[RFC-1122] Braden, R., Ed., "Requirements for Internet Hosts --
Communication Layers", RFC-1122, October 1989.
Security Considerations
See Section 5 of this memo.
Braden, Postel, Rekhter Expires: April 1994 [Page 15]
Internet Draft Shared Media IP Architecture October 1993
Authors' Addresses
Bob Braden
University of Southern California
Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292
Phone: (213) 822-1511
EMail: Braden@ISI.EDU
Jon Postel
University of Southern California
Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292
Phone: (213) 822-1511
EMail: Postel@ISI.EDU
Yakov Rekhter
Office 32-017
T.J. Watson Research Center, IBM Corp.
P.O. Box 218,
Yorktown Heights, NY 10598
Phone: (914) 945-3896
EMail: Yakov@WATSON.IBM.COM
Braden, Postel, Rekhter Expires: April 1994 [Page 16]